
\section{Introduction}
\label{sec:intro}

Fuzzing is a common technique used to perform automatic software testing. It starts with a user-provided initial input. A number of mutations are performed against the initial input to generate more test inputs. Test inputs are then used for fuzzing and testing if any unexpected behavior, e.g., crash, can be triggered by the program.
%
A tool used to perform fuzzing test is often called a fuzzer.
One popular class of fuzzers is grey-box fuzzers.
Grey-box fuzzers collect runtime states from a program under testing, and it, therefore, achieves a balance between efficiency and effectiveness, compared to white-box and black-box fuzzers.

Most grey-box fuzzers require source codes to perform a fuzzing test.
This is because the most efficient approach to collect program runtime states is to perform static instrumentation when compiling a program.
Codes used to collect runtime states are embedded into a compiled program so that runtime states can be reported to the fuzzers in a fuzzing process.
However, source codes may be not accessible for security engineers, and it shows the demand on grey-box based fuzzing for binaries.

To our knowledge, the American Fuzzy Lop (AFL)~\cite{AFL} is the only one grey-box fuzzer that support binary fuzzing. However, recent grey-box fuzzers such as \libfuzzer~\cite{libfuzzer} find crashes faster than AFL in several cases. It might because \libfuzzer considers more runtime states than AFL. Currently, \libfuzzer still has to work with source codes. Therefore, in this paper, we attempt to design and implement a binary fuzzer based \libfuzzer and see what would be the critical factor to affect the performance of fuzzing.
